General Comments

A few remarks about efficiency and quirks:

• In most of the above commands, simply typing a <#210#>[]<#210#> for optional arguments with <#211#>nothing<#211#> as the value will either cause an error or will be interpreted as a null value; hence a <#212#>[]<#212#> should not be typed if an optional argument is not meant to be specified.

• If too many ``dots'' are to be plotted in one picture, it is suggested that a character other than the default be used --- about 40--50 more dots can be plotted in a picture using a period (.) or a 95 (•) in various sizes, rather than the default 96, although the latter seems to have a better visual appearance. The use a 97 also enables one to have a better control over the thickness of dots and lines.

  A note on efficiency: when specifying a font or a fontsize for a character it is more efficient to say:
  98, rather than
  99.
  In the latter case, 100 macro gets invoked for <#213#>each<#213#> instance of the dotcharacter 101 as the dottedline is plotted.

• If it is not very important as to how accurately spaced a dashed line appears, then it is suggested that 102 command with a -ve stretch be used instead of 103, since the former is much more cpu- and memory-efficient.

• 104 and 105 come out much too thin with 106. Moreover, the thicker the 107, fewer ``dots'' are required to construct dashes resulting in lesser memory and cpu usage. Thus, it is recommended that they be plotted with 108 in effect, or with a linethickness of about 1--2pt.

• In the case of 109, any explicit linethickness declarations (i.e. using 110 command) are ignored. The only applicable declarations are 111 and 112 since line-segment fonts are available in only two thicknesses.

Above commands are available in the picture environment only since they use many of the L^ATEX's predefined picture commands. Extensive use of some of the internal macros and variables of L^ATEX has been made for efficiency sake, even though that makes these macros vulnerable to future revisions of L^ATEX.

The dottedline macro gets complicated because TEX does not have any builtin facility for floating point calculations or for calculating square-roots or trigonometric functions. The inter-dot-gap in a dottedline has to be treated as the actual distance between two dots along the ``hypotenuse'' and not its projected distance along x-axis or y-axis, since the latter interpretation would result in a different <#215#>real<#215#> inter-dot-gap for different slopes; it would be incorrect if we were joining points on a graph. The dootedline macro treats the inter-dot-gap as the actual distance between two dots and draws the various segments of the ``curve'' with this distance fixed. The macro accomplishes this by estimating the actual length of the line and the number of segments of the specified distance that will fit between the two end-points; a macro, namely, 113 calculates this square-root. Some algebraic relations are used in estimating this square-root and are described in appendix A.

Beware, if far too many dots are put in one picture, L^ATEX will run out of memory (box full), so be kind to it. For instance, by reducing the inter-dot-gap to about 0.3mm in the case of a 114, one can get essentially a solid line, but that would mean a LOT of dots and it may run out of memory.

If many lines using above-mentioned macros are drawn, then a 115 ought to be put at judicious places in the document so as to tell L^ATEX not to keep those figures floating -- L^ATEX sometimes keeps entire figures in memory while trying to figure out how and where to lay them and it can frequently run out of memory. A 116 may prevent running out of memory and may reduce execution times. In case of such a memory-full error message, a 117 in the region where the error occurred should be attempted first and if that does not help then the number of ``dots'' in the picture will have to be reduced.

A word about 118 is in order. L^ATEX's 119 command takes an ordered pair of integers to specify the slope of the line where the numbers are between -6 and 6 such that the least common divisor is 1. For the 120 command, the given arbitrary slope has to be mapped to the pair of integers representing the <#216#>closest<#216#> available slope. Another macro, 121 is used to accomplish this task. The macro 122 takes two arguments, the base and the height of the triangle whose hypotenuse represents the line to be drawn and returns the ordered pair of integers representing the closest slope; using a line segment of that slope, a jagged line between the two specified end-points is then constructed. More details can be found in the macro file <#217#>epic.sty<#217#>.

As noted earlier, the command 123 behaves identically as 124 when not in any of the join environments. The author considered obliterating the 125 command too radical a step. Also, there should have been a command 126 corresponding to the 127 command (like the 128 command) but that was considered unnecessary since typically the number of coordinates plotted in a join environment would be an order less than what might be the case with 129 and can be easily typed explicitly in the document using 130 commands. However, if it is desired to have all the 131 commands treated as though they were 132, the following declaration may be used:
133
Above declaration will make all the 134 commands be treated as 135; in particular, 136 command would then behave as though it were a 137 when in any of the join environments. However, it is suggested that such ``tricks'' be used with care.

Finally, commands to plot vectors of arbitrary slopes have not been implemented. One way to plot them is to plot a line, and subsequently plot a 138 of appropriate slopes and length zero at the required place.

Following pages contain some examples. The test-sample picture for 139 command (Figure~2) is also about the maximum amount of objects that one can put in one picture. Older versions of TEX and L^ATEX may not be able to print pictures of this size.

<#232#>picman-fig1<#232#>

<#292#>picman-fig3<#292#>